The present invention generally relates to an improved processor. The present invention more particularly relates to such a processor which is capable of more efficiently handling second level exception conditions.
Microprocessors are well known in the art. One type of processor is a reduced instruction set (RISC) processor having a pipelined architecture. Such processors process serial instructions through a series of stages including, for example, a fetch stage, a decode stage, an execute stage and a write-back stage. Such processors operate at very high speeds and due to their pipelined architecture, are capable of efficiently executing instructions with a minimum of hardware.
In such processors, each instruction is processed through the aforementioned stages. Hence, during one cycle, a first instruction will be in the write-back stage, a second instruction will be in the execute stage, a third instruction will be in the decode stage, and a fourth instruction will be in the fetch stage. In the immediately succeeding cycle, the second instruction will be in the write-back stage, the third instruction will be in the execute stage, the fourth instruction will be in the decode stage, and a new or fifth instruction will be in the fetch stage.
Such processors also generally include an exception handler. Exception handlers are also well known in the art. The exception handlers are utilized in such processors to process non-routine instructions. Non-routine instructions invoke in the processor what is known as an exception condition. Exception conditions may arise, for example, when an instruction calls for an invalid operation, when an instruction calls for a division by zero, or when the execution of an instruction will cause an overflow or underflow condition.
When an exception condition is noted during the execution of an instruction, normal processing is interrupted and the processor must save the context of the interrupted process by noting the process status of each instruction currently in process. The exception handler must then invoke a software routine to determine the cause of the exception condition and process the exception condition by performing any functions the exception requires. After the exception condition is handled, the processor must then return to the normal process for each instruction which was being processed, at the process point for each such instruction when the exception condition occurred.
Prior art processors, upon detecting an exception condition, have saved the context of the interrupted process by storing the same in external memory. Storing the context of the interrupted process in external memory causes a problem in the form of increased exception latency because it increases the time required from receipt of an exception to the execution of the exception by the exception handler. This is especially the case if memory access times are long compared to processor register access times.
To overcome the exception latency problem, one prior art processor continuously saves its context in internal registers which are prevented from being updated upon the detection of an exception. The exception handler can then execute the exception directly because the processor context is frozen in the internal registers.
While the internal register approach has reduced exception latency, the exception handler is only capable of executing first level exceptions, exceptions occurring in the normal process. Unfortunately, at times, exceptions can occur during the execution of an exception itself. These exceptions are referred to as second level exceptions and cannot be handled by such processors unless specialized first level exception handler software is provided. Standard exception handling tools such as setting break points and tracing program flow cannot be used since exceptions are disabled during the execution of first level exceptions in such processors. As a result, second level exceptions are either not detected or are ignored altogether.
The present invention overcomes the aforementioned problems in handling exceptions. It not only provides a means by which second level exceptions can be efficiently executed but also, avoids the problems of exception latency.